Operational semantics for signal handling

Signals are a lightweight form of interprocess communication in Unix. When a process receives a signal, the control flow is interrupted and a previously installed signal handler is run. Signal handling is reminiscent both of exception handling and concurrent interleaving of processes. In this paper, we investigate different approaches to formalizing signal handling in operational semantics, and compare them in a series of examples. We find the big-step style of operational semantics to be well suited to modelling signal handling. We integrate exception handling with our big-step semantics of signal handling, by adopting the exception convention as defined in the Definition of Standard ML. The semantics needs to capture the complex interactions between signal handling and exception handling.Comment: In Proceedings EXPRESS/SOS 2012, arXiv:1208.244

Benchmarking implementations of functional languages with ‘Pseudoknot', a float-intensive benchmark

Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical' applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varie

A visual Lisp debugging environment

technical reportGraphics provides a useful tool for visualizing the behavior of computer programs. Diagrams can be be used to illustrate both the control structure of the program and the data structures operated upon by the program.; The integration of graphics into two traditional debugging tools, a program stepper and a data structure inspector, is described. Diagrams for both systems are produced using the same hierarchical layout package and make use of similar mechanisms for pruning and elision of the display. As part of the program stepper, an integrated framework has been developed to support both prospective (active) debugging methodologies such as stepping and tracing, and inspective (passive) methodologies such as backtracing and program history. This framework makes use of both hooks in the interpreter and annotations to the code. It allows multiple, arbitrary trace functions to be invoked at each evaluation step, and can be used in both compiled and interpreted code